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ABSTRACT 


Numerous  vehicles  drivers  know  about  the  driving  practices  and  propensities  that  can  prompt  wasteful  and  perilous  driving.  In  any  case,  it  is  frequently  the  case  that 
these  same  drivers  unconsciously  display  these  wasteful  and  dangerous  driving  practices  in  their  regular  driving  action.  This  paper  proposes  a commonsense  and 
temperate  approach  to  catch,  measure,  and  ready  drives  of  wasteful  and  perilous  driving.  The  proposed  arrangement  comprises  of  a portable  application,  running  on  a 
current  cellphone  gadget,  combined  with  a perfect  OBD-II  (On-board  diagnostics  II)  peruser. 
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Introduction 

There  are  a few  estimations,  which  can  be  utilized  alone  or  as  a part  of  mix,  that 
can  show  if  a driver  is  driving  perilous  or  wastefully.  A little  subset  of  these  esti- 
mations incorporates: 

• Deceleration 

• Vehicle  Speed 

• Detection  of  faults  in  Safety  or  Mechanical  Equipments  Environment  Con- 
ditions (Eg.  Traffic,  Temperature)  Rate  of  Fuel  Consumption 

• Engine  RPM 

In  spite  of  the  fact  that  these  estimations  can  decide  the  wellbeing  and  productiv- 
ity of  driving  movement,  there  has  not  been  a down  to  earth  approach  to  catch  and 
show  these  information  to  the  ordinary  driver  in  a way  that  can  affect  the  driver's 
conduct  continuously  or  in  a way  in  which  it  could  be  inspected  and  considered  in 
a verifiable  sense. 

A.  Capturing  Safety  and  Efficiency  Measurements 

In  the  past  catching  these  estimations  has  been  unfeasible  for  the  normal  driver. 
These  sorts  of  estimations  must  be  caught  in  a controlled  domain  or  through  the 
utilization  of  costly  and  particular  gear.  Current  cell  phones,  as  cell  phones,  now 
have  large  portions  of  the  general  elements  required  by  this  specific  hardware. 
These  components  incorporate  a client  interface  to  acknowledge  enter  and  show 
yield,  figuring  energy  to  run  ongoing  counts,  the  capacity  to  run  particular  appli- 
cations, and  the  capacity  to  store  and  recover  information  both  locally  and 
remotely  (e.g.  Web  and  GPS).  Conveying  these  components  to  a cell  phone  has 
decoupled  huge  numbers  of  the  elements  that  made  these  specific  gadgets  costly 
or  unfeasible  for  the  regular  driver.  It  is  assessed  that  23%  of  versatile  customers 
now  have  a cell  phone  [1].  Since  a hefty  portion  of  these  versatile  stage  makers 
(i.e.  Apple,  Google,  and  so  on.)  have  opened  up  their  gadgets  to  acknowledge  out- 
sider equipment  and  programming.  The  force  of  these  cell  phones  can  now  be 
matched  with  less  costly  concentrated  gear  that  does  not  need  to  reproduce  or 
incorporate  the  components  that  are  accessible  on  the  cell  phone.  At  the  point 
when  the  components  of  a cutting  edge  cell  phone  are  combined  with  a cheap 
OBD-II  per  user,  the  cell  phone  turns  into  a capable  device  that  can  specifically 
correspond  with  the  vehicle's  Engine  Control  Unit  (ECU).  Doing  as  such  permits 
the  cell  phone  to  catch,  decipher,  and  show  ongoing  information  that  points  of 
interest  the  flow  condition  of  the  vehicle,  and  in  addition  measures  the  driver's 
collaborations  with  the  vehicle.  An  OBD-II  per  user  is  a gadget  utilized  for  inves- 
tigating issues  with  a vehicle  or  recover  continuous  execution  information  by 
interfacing  straightforwardly  to  a vehicle's  ECU.  In  1996  a law  was  passed  that 
made  it  required  for  all  vehicles  sold  in  the  United  States  to  bolster  the  OBD-II 
detail. 

B.  Recent  Use  of  this  Technology 

As  of  late,  in  the  versatile  application  advertise,  a few  applications  have  risen  that 
match  the  force  of  a cell  phone  with  the  data  accessible  through  the  utilization  of 
an  OBD-II  per  user.  These  applications  have  a tendency  to  be  coordinated  toward 
auto  fans,  creating  highlights  that  focus  on  measuring  vehicle  execution  and 
investigate  mechanical  issues  [2].  Different  applications  are  surfacing  that 
emphasis  on  ecological  concerns  [3].  These  applications  focus  on  elements  such 
as  measuring  a driver's  carbon  foot  shaped  impression  and  fuel  utilization.  Some 
of  these  applications  incorporate  elements  that  can  recognize  security  issue  (e.g. 
issues  with  the  vehicle's  security  control  framework).  Then  again,  these  compo- 


nents are  centered  around  recognizing  mechanical  issues  with  wellbeing  gear, 
not  on  distinguishing  constant  worries  with  the  driver's  conduct  or  environment. 

C.  Mobile  Application  Concept 

This  paper  strolls  through  the  improvement  procedure  of  a portable  application 
that  is  essential  target  is  to  catch,  measure,  and  caution  clients  of  dangerous  and 
wasteful  driving.  "How's  The  Ride?"  is  a product  application  that  will  screen, 
record,  and  show  ongoing  vehicle  information  to  the  driver  of  a car.  The  applica- 
tion will  give  continuous  criticism  empowering  the  driver  to  alter  his  or  her  driv- 
ing style  to  be  more  secure,  smoother,  and  more  productive.  The  application  is  a 
model.  The  final  item,  as  not  yet  completely  created,  will  require  heartier  testing 
and  include  tuning  before  it  can  be  viewed  as  an  attractive  application.  Rather, 
the  model  displayed  in  this  paper  ought  to  be  dealt  with  as  a proof  of  idea  figuring 
out  whether  a cell  phone  can  be  sufficiently  hearty  to  catch,  measure,  and  ready 
drivers  of  dangerous  and  wasteful  driving  conduct.  What's  more  the  gear  must  be 
commonsense  in  cost  and  usability. 

Materials  and  Methods: 

In  spite  of  the  fact  that  this  application  is  a model,  the  application  will  have  some 
broad,  yet  strict,  utilitarian  and  nonfunctional  prerequisites. 

A.  Functional  and  Non-Functional  Requirements 
1)  Real  Time  View  Safety  and  Efficiency  Measurements 

The  application  must  give  at  least  three  of  the  accompanying  estimations  to  track 
security  and  effectiveness  recorded  in  Table  1 . 


TABLE  I:  POTENTIAL  SAFETY  AND  EFFICIENCY  MEASURE- 
MENTS 


Measurement 

Description 

Acceleration 

Positive  change  in  velocity  over  time.  Accelerating 
too  quickly  can  be  considered  inefficient  and  unsafe. 

Deceleration 

Negative  change  in  velocity  over  time.  Decelerating 
too  quickly  can  be  considered  inefficient  and  unsafe. 

Speed  of  Vehicle 

Measured  in  MPH.  Distance  divided  by  time. 
Driving  too  fast  can  be  considered  inefficient. 

Detection  of  Safety 
Equipment  Issues 

Determining  faults  in  the  vehicle’s  safety  equipment. 
Driving  with  faulty  safety  equipment  is  dangerous 

Detection  of 
Mechanical  Issues 

Determining  equipment.  Mechanical  faults  can 
impact  safety  and  efficiency. 

MPG 

Miles  Per  Gallon.  Driving  style  can  have  a positive  or 
negative  impact  on  the  rate  that  a vehicle  uses  fuel. 

Location 

Geographic  location.  Can  be  used  in  conjunction 
with  other  data  to  pinpoint  location  of  inefficient  or 
unsafe  driving. 

Weather  & 
Traffic 
Conditions 

Current  conditions  of  the  weather  or  traffic.  When 
paired  with  location,  this  measurement  can  be  used  as 
a variable  in  determining  unsafe  driving. 

Engine  RPM 

Revolutions  per  minute. 

Can  be  used  to  detect  inefficiency  such  as  revving  or 
over-  taxing  an  engine. 

These  estimations  ought  to  be  shown  to  the  client  progressively  cautioning  the  cli- 
ent  of  dangerous  and  wasteful  conduct. 
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2)  Logging  of  Data 

At  the  point  when  an  issue  is  recognized,  the  application  will  log  a compressed 
rendition  of  the  issue  on  a five  second  interim.  The  five  second  interim  is  required 
in  light  of  the  fact  that  continuously  mode,  these  estimations  might  be  gathered 
and  showed  on  an  a great  deal  more  successive  premise.  This  interim  permits  the 
information  to  be  compressed  in  a more  significant  manner. 


2)  Selection  of  Relevant  OBD  Reader 

The  OBD-II  reader  supports  three  main  types  of  connectivity’s, 

a.  Bluetooth  Connectivity 

b.  Wi-Fi  Connectivity 


3)  Reflective  view 

The  application  will  give  an  intelligent  perspective  that  shows  perilous,  wasteful, 
or  sketchy  driving  conduct  from  the  outlined  information  gathered  in  prerequi- 
site #2. 

This  perspective  must  show  the  information  meaningfully  that  permits  the  client 
to  consider  what  patterns  or  natural  variables  might  have  set  off  the  undesired 
conduct  (e.g.  converging  on  to  a roadway).  In  particular,  this  perspective  ought  to 
be  accessible  in  the  verifiable  sense,  not  requiring  any  connection  while  driving. 

4)  Platform 

The  application  will  keep  running  on  a cutting  edge  cell  phone  gadget. 

5)  Performance  (Progressive  Mode) 

Progressively  mode,  vehicle  estimations  showed  to  the  client  must  be  upgraded 
at  least  once  every  second. 


c.  Direct  Connectivity 

Among  all  three  types,  the  direct  connectivity  requires  a wired  connection  which 
rises  complexity  of  connection  & its  very  less  efficient.  Secondly  the  Wi-Fi  con- 
nectivity although  being  efficient  enough,  it  is  very  costly  to  setup  a Wi-Fi  con- 
nectivity for  this  system.  Here  the  target  connectivity  used  is  the  Bluetooth  con- 
nection as  it  is  very  common  and  cheaper  option  providing  greater  efficiency  in 
terms  of  cost,  performance,  setup  and  outputs  etc. 

C. Interface 

1)  Settings  View:  Here  the  limits  of  the  estimations  that  ready  clients  of  hazard- 
ous or  wasteful  driving  can  be  balanced.  This  figure  demonstrates  the  Setting 
View.  This  perspective  is  important  in  light  of  the  fact  that  every  vehicle  is  dis- 
tinctive. In  spite  of  the  fact  that  default  settings  are  given,  this  perspective  gives  a 
client  the  capacity  to  begin  with  less  strict  settings  and  diminishes  the  limit  as 
their  driving  makes  strides 


6)  Performance  (Continuos  Mode) 

Continuously  mode,  record-breaking  basic  estimations  subject  to  outsider  gad- 
gets (e.g.  system  correspondence)  must  endeavor  to  upgrade  once  consistently. 

7)  Usability 

Ceaselessly  mode,  record-breaking  essential  estimations  subject  to  outcast 
devices  (e.g.  framework  correspondence)  must  try  to  redesign  once  reliably. 

8)  Performance 

At  the  point  when  the  application  is  checking  the  driver  progressively  mode,  the 
application  ought  not  to  require  direct  communication  with  the  touch  screen. 

System  Design: 

A.  System  Architecture 

At  the  point  when  the  application  is  observing  the  driver  progressively. 
The  framework  building  design  comprises  of  an  OBD  gadget,  An  advanced 
mobile  phone  having  android  stage,  an  android  application,  a server  and  related 
database.  The  OBD  per  user  gadget  get  to  the  motor  insights  and  execution  esti- 
mations utilizing  its  inbuilt  sensors  and  vehicle  sensors.  This  gadget  has 
Bluetooth  availability  through  which  it  is  associated  with  the  advanced  mobile 
phone.  The  android  application  gets  the  measurements  from  the  OBD  and  sends 
it  to  the  server  by  means  of  web.  The  server  sends  a ready  message  to  the  propri- 
etor on  getting  the  statistics.ode,  the  application  ought  not  require  direct  associa- 
tion with  the  touch  screen. 


FIGURE  1:  SYSTEM  ARCHITECTURE 

B.  Hardware  Selection 
1)  Selecting  a Smartphone  Device 

Today  there  are  four  dominant  Smartphone  devices  on  the  market.  For  this  appli- 
cation, the  Android  OS  has  been  targeted. 

Although  many  of  the  other  Smartphone  devices  offer  several  of  the  same  fea- 
tures as  the  Android,  the  number  of  applications  available,  the  consistency  of 
hardware  between  different  versions  of  the  device  and  the  potential  to  run  the 
application  on  non-phone  mobile  devices  (e.g.  Android  Tabs,  Android  TV  etc.) 
make  the  Android  OS  the  most  attractive. 
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FIGURE  2:  SETTINGS  VIEW 

2)  Real-Time  View:  This  screen  demonstrates  the  Real-Time  View.  This  is  the 
primary  view  that  will  be  shown  when  a client  is  driving.  This  perspective 
requires  no  client  communication,  as  this  would  occupy  the  driver.  Continuous 
information  is  caught  and  showed  to  the  client  while  this  perspective  is  dynamic. 
The  three  gages  at  the  highest  point  of  the  perspective  showcase  RPM,  MPH  and 
Acceleration  in  FPS2.  At  the  point  when  one  of  these  three  estimations  is  met  or 
surpassed,  the  perusing  for  that  estimation  turns  from  yellow  to  red,  and  an  alarm 
is  logged.  A pin,  speaking  to  the  alarm,  is  then  dropped  on  the  guide  to  speak  to 
the  area  where  the  occasion  happened.  Normal  MPG  and  Instant  MPG  will  like- 
wise turn  red  if  the  vehicle  comes  to  or  surpasses  the  set  limit.  On  the  other  hand, 
these  measures  won't  log  alarms,  as  they  are  not  firmly  connected  to  area.  Addi- 
tionally, the  change  of  moment  MPG  is  excessively  visit  for  a condensed  per- 
spective of  this  data  to  be  important.  Two  different  estimations  are  incorporated 
into  this  perspective.  These  estimations  are  included  in  light  of  the  fact  that  they 
are  a piece  of  the  MPG  count.  These  estimations  are  Gallons  Used  and  Miles 
Driven.  In  spite  of  the  fact  that  they  may  not  specifically  identify  with  measuring 
proficiency,  they  give  worth  to  the  individuals  who  are  following  their  fuel  mile- 
age. These  two  estimations  are  spared  when  the  application  is  shutdown  and 
restarted.  This  keeps  up  the  Average  MPG  estimation  after  some  time. 
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FIGURE  3:  REAL  VIEW 


Conclusions: 

This  paper  presented  some  sort  of  structure  and  a prototypical  process  pertaining 
to  real-time  vehicle  keeping  track  of  along  with  traveling  guidance.  Data  pro- 
duced by  using  OBD-II,  via  mobile  phone  micro-devices  along  with  Net  prod- 
ucts and  services  is  utilized  to  help  annotate  this  framework  pertaining  to  addi- 
tional semantic-based  inferences.  Upcoming  function  incorporates  other 
improvements  towards  the  portable  prototype,  at  the  grams,  speech  notifications 
along  with,  in  terms  of  research  can  be  involved,  additional  OBD  variables  along 
with  mobile  phone  peripherals  (at  the  grams,  digicam,  microphone)  could  possi- 
bly double  along  with  real  names  built  into  reference  point  logic  different  lan- 
guages. 
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